![[レポート] Amazon Neptune を使用した顧客のユースケース #DAT220 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2019/12/reinvent2019_report_eyecatch.jpg)
[レポート] Amazon Neptune を使用した顧客のユースケース #DAT220 #reinvent
こんにちは、岩城です。
セッション「Real-world customer use cases with Amazon Neptune」 を聴講しましたのでレポートします。
概要
Why do you need a graph database? In this session, we deep dive into the use cases of Amazon Neptune. You hear from Uber and NBCUniversal about how they have deployed highly scalable graph solutions with Neptune. This session also covers the companies’ design decisions, the lessons they learned, and their experiences with this service.
Google翻訳
グラフデータベースが必要な理由は何でしょうか。このセッションでは,Amazon Neptuneの使用例について詳しく説明します。 UberとNBCUniversalから、Neptuneで高度にスケーラブルなグラフソリューションを展開した方法について聞いています。このセッションでは、企業の設計上の決定、彼らが学んだ教訓、およびこのサービスでの経験についても説明します。
- Session Type
- Session
- Topic
- Databases
- Session Level
- 200 - Intermediate
スピーカー
- Karthik Bharathy
- Product Leader, Amazon Neptune, Amazon Web Services
- Yazen Shunnar
- Software Engineer, Uber
- Elliott Foster
- Software Architect, NBC Universal
レポート
グラフはどこにでもある
- 検索エンジン
- 接続、閲覧、フォローしているSNS
- 参加しているプロフェッショナル・ネットワークサービス(LinkedInみたいな)
- 旅行予約
- 出席している会議
- 所持しているデバイス
- インターンネットは一つ大きなグラフ
グラフユースケース
- SNS
- レコメンデーション
- ナレッジグラフ
- 不正検出
- ライフサイエンス
- ネットワークおよびIT運用
Amazon Netptune の特徴
- Fast
- ミリ秒の遅延で数十億のリレーションを参照
- Reliable
- 3つのAZに6つのデータのレプリカを使用し完全バックアップとリストアが可能
- Easy
- GremlinとSPARQLを使用して強力なクエリを簡単に作成
- Open
- Apache TinkerPopおよびW3C RDFグラフモデルをサポート
Neptuneの新機能
- Neptune Streams
- グラフに加えられたすべての変更を記録する変更ログエントリの完全なシーケンスを生成
- Transaction semantics
- データの異常を回避するための形式化されたセマンティクス
- Gremlin/SPARQL Explain
- クエリプランと評価順序に関するinsightを得る
- SPARQL 1.1 Federated Query
- SPARQLを使用して、さまざまなデータソースにわたってクエリを記述
- Gremlin sessions
- クライアントはセッションの転送を開始。セッション中に実行されるすべてのクエリは、接続が閉じられた後にのみコミットされる
- Database cloning
- copy-on-writeセマンティクスを使用してDBクラスターの複数のクローンを作成する
- Elasticsearch integration
- NeptuneのグラフデータでElasticsearchを使用した全文検索
- Neptune Workbench(New)
- グラフを照会するためのコンソール内のノートブックエクスペリエンス
Neptuneの顧客
ユースケース:NBCUniversal
抱えていた問題点
- レガシーデータストア
- 前年比成長
- 運用の複雑さ
- スケールアップとスケールダウンが必要
Neptuneに決めた理由
- グラフDB:jobに最適なツール
- 早期採用は難しい
- AWSエンジニアからの素晴らしいサポート
- Gremlinは自然で使いやすい
積極的な移行
- 既存の機能を保持しながら、パフォーマンスを改善する
- ライブトラフィックと並行してプロトタイプを作成する
- 市場投入までの時間を短縮するソリューション
シンプルなアーキテクチャ
移行中のシステムパフォーマンス
スループットが上がり、レスポンス時間が下がった。
現在
- レガシーシステムの2倍以上の書き込みスループットに改善
- 読み取り応答時間を1桁以上改善
- スケーリングおよびダウンシンクイベントの管理がより簡単に
- レガシーに比べて最大40%のコスト削減
- 成長する余地がたくさんある!
学んだこと
- グラフ全体を戻し、簡単に書き込める
- フェールオーバーロジックのため、クラスターのサイズを適切に設定するのは難しい
- データモデル駆動でアプリケーションロジックを考える必要があった
次のステップ
- ユーザーエンゲージメントを高めるためのさらなるパーソナライズ
- データとユーザーがどのように対話しているかより深く洞察する
- GraphQLインターフェース
ユースケース:Uber ATG
- Uber ATGは、自動運転技術を開発している。
- 本セッションは、Neptuneを自動運転に用いるマップで利用したユースケース
- Uber ATGでは、いくつかの都市で自動運転をテスト実行しており、その都市のひとつがピッツバーグ
ピッツバーグのバージョングラフ
- 各ドットはマップのバージョンを表し、各エッジはマップの頂点間の親子関係を表す
- マップバージョンの数はX千、マップのデータはXテラバイト
- アクセス要件
- バージョン編集は1秒未満
- バージョン作成は0.01秒未満
グラフモデリング
- Vertexは編集内容のみを保存
- Vertexの編集はタイムスタンプでソートされる
- Edgeを通って親データを見つける
Why Neptune?
- モデルをグラフとして簡単にバージョン管理可能
- 垂直方向にスケーラブル(スケールアップ)な書き込み可能
- 水平方向にスケーラブル(スケールアウト)な読み取り可能
- フルマネージド
Neptune利用で得た経験
- Gremlinのクエリ言語はシンプルで、自然に問題をモデル化可能
- 多種多様なインスタンスタイプがありスケールアップ可能
- リードレプリカの作成は簡単
- リードレプリカ伝播速度は平均20ms以下
- 非常に高速なトラバーサル
- 監視ツールはシンプルで直感的
注意すべきこと
- Neptuneのクラスターエンドポイントはセッション持続性を伝播する
- データを削除するよりも速くデータを追加する
- Gremlin GoLangクライアントが開発中
最終結果
- Neptuneによって管理される1PB以上のデータはS3に保存されている
- データ編集は平均0.1秒以下、バージョン作成は平均0.01秒以下
- マップストレージ全体がNeptuneで管理されている
(ユースケースの紹介終わり)
まとめ
- NBCUniversal
- Neptuneを使用して1秒あたり3万件以上のリクエストを処理
- NoSQLデータベースからAmazon Neptuneに移行
- 総コストを40%削減
- Uber ATG
- 高解像度マップを管理するためのマイクロサービスを構築
- Amazon Neptuneを使用して、マップ上の数十億のリレーションシップを処理し、ミリ秒単位でクエリ
おわりに
Neptuneについての知識を増やそうと思っており、本セッションを聴講しました。 そもそもグラフDBに関する基礎知識が乏しく理解するまでにすごく時間が掛かってしまいました。 グラフDBについてもっと知識を増やそうと思います。
本エントリがどなたかのお役に立てれば幸いです。